Logs here: ConvertResourcesCases.zip

I love this idea. It will bring major improvements for our customers.
The only downside is it will only benefit customers using the newest versions for the support libraries and the newest version of XA. The Custom Attribute will only be able to be used by support libraries built against the latest version. Not sure what would happen when a user tries to use that nuget from an older version of XA?
Can this custom attribute somewhere else that can be shared via a nuget?

Perhaps we can have a backup which uses the assembly name/info which does a similar thing so that we can bring this improvement to people using older versions of the support libraries.

If we want a build of the support libraries, they could add a file like this to their projects:

//SkipAndroidResourceProcessingAttribute.cs
[assembly: SkipAndroidResourceProcessing]

namespace Xamarin.Android.Support
{
	[AttributeUsage (AttributeTargets.Assembly)]
	public sealed class SkipAndroidResourceProcessingAttribute : Attribute
	{
	}
}

They could do this right now, even before an updated Xamarin.Android is out. (if an assembly attribute is the way we want to go)

The [assembly:LinkerSafe] attribute works this way, too. You can add an attribute named the same in a NetStandard lib, and it works because the name of the attribute matches: https://github.com/mono/linker/blob/44199a2c62ff221f92c33cbb4ee3e35588adaf4a/tuner/Mono.Tuner/CustomizeActions.cs#L47

We can for sure get this in the 28.x version of the support libs, and we might need to backport it to the version that Xamarin.Forms is using.

Discussed this recently: We won't take this as-is.

The problem with an assembly-level attribute which skips all processing of the resources contained within the assembly is that it's brittle. Imagine:

1. Dev creates a binding assembly for a .aar

2. Dev enables [assembly: Android.SkipAndroidResourceProcessing]

3. "Later," dev adds a custom View C# subclass and uses that View via it's C# name in a .axml file, within the same project.

   In order for this to work, <ConvertResourceCases/> must be invoked on that .axml file.

4. App.csproj builds after (3) result in apps which throw an exception during runtime IFF the .axml from (3) is loaded (which might not be caught by unit tests!).

This is brittle. :-)

Long term, we want to be able to use this optimization, but however we provide it, it needs to not be brittle in the face of the above scenario.

We talked this through and we have a plan:

Long Term

We figure out how to do this in a nicer way, where you won't as easily be able to mess it up. Someone could add the assembly attribute without knowing it will break their layouts. This might involve redoing how __AndroidLibraryProjects__.zip works.

Short Term

We are just going to "whitelist" assemblies to skip with an <ItemGroup/> such as:

<ItemGroup>
  <_AndroidAssemblySkipCases Include="Xamarin.Android.Support.v7.CardView" />
  <_AndroidAssemblySkipCases Include="Xamarin.Android.Support.v7.AppCompat" />
  <!--Etc-->
</ItemGroup>

If we get in a tight spot, additional assemblies could be added/removed from this <ItemGroup/> without an update to Xamarin.Android.

Then our MSBuild tasks will treat @(_AndroidAssemblySkipCases) as case-insensitive list of assemblies to skip for ConvertResourcesCases.

Updated logs: ConvertResourcesCases2.zip

After using HashSet<string>, I don't think ResolveLibraryProjectImports has any performance slow down. I think it might actually be a little faster because I removed some LINQ, and duplicate Path.GetFullPath calls.

Latest logs (set no. 3) here: ConvertResourcesCases3.zip

Whoops, looking into the test failure